Protecting enterprise data at each system layer

ABSTRACT

One embodiment provides a method, including: utilizing at least one processor to execute computer code that performs the steps of: receiving, on an electronic device, a request to execute a system process; determining, using a processor, if the electronic device contains enterprise information; thereafter, identifying, based on the request, that the system process is associated with enterprise information; and granting, to a software platform, restricted access to the enterprise data using a hypervisor. Other aspects are described and claimed.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority to India Patent Application Serial No.201641016304, filed on May 10, 2016, and entitled “PROTECTING ENTERPRISEDATA AT EACH SYSTEM LAYER,” the contents of which are incorporated byreference herein.

BACKGROUND

Mobile Electronic devices (e.g., smart phones, tablets, laptops, etc.)are more common today than ever before. As the capability of thesedevices has increased, so has their role in our lives. Actions thatwould have previously only been carried out on a computer, such asbanking, shopping, gaming, etc., are now done on mobile devices. Becauseof this increase capability, our mobile devices are being granted accessto more confidential and important information than ever before. Forexample, many individuals access their bank account via their mobiledevices, and perhaps even save their credentials locally on the mobiledevice.

Additionally, as the lines between work and home blur for many businessfocused individuals personal and enterprise information regular end upon the same device. For example, a user may have a personal smart phoneor tablet that has access to enterprise information associated withtheir employment. For example, the user may have their business emailreceived on their device, or may have a virtual private network (VPN)connection the enterprise servers. This can be a cause of concern forbusinesses as individuals are not as security focused as corporationsneed to be. This can lead to data exposures cause by weaknesses in thepersonal aspect of a user's device. For example, a user may mistakenlyallow a malicious individual to gain access to their device, and becausethe user's device has access to enterprise data, the maliciousindividual now has access to any information available to the worker(e.g., confidential business information).

BRIEF SUMMARY

In summary, one aspect of the invention provides a method comprising:utilizing at least one processor to execute computer code that performsthe steps of: receiving, on an electronic device, a request to execute asystem process; determining, using a processor, if the electronic devicecontains enterprise information; thereafter, identifying, based on therequest, that the system process is associated with enterpriseinformation; and granting, to a software platform, restricted access tothe enterprise data using a hypervisor.

Another aspect of the invention provides an apparatus comprising: anapparatus comprising: at least one processor; and a computer readablestorage medium having computer readable program code embodied therewithand executable by the at least one processor, the computer readableprogram code comprising: computer readable program code that receives,on the apparatus, a request to execute a system process; computerreadable program code that determines, using a processor, if theapparatus contains enterprise information; computer readable programcode that thereafter, identifies, based on the request, that the systemprocess is associated with enterprise information; and computer readableprogram code that grants, to a software platform, restricted access tothe enterprise data using a hypervisor.

An additional aspect of the invention provides a computer programproduct comprising: a computer readable storage medium having computerreadable program code embodied therewith, the computer readable programcode comprising: computer readable program code that receives, on anelectronic device, a request to execute a system process; computerreadable program code that determines, using a processor, if theelectronic device contains enterprise information; computer readableprogram code that thereafter, identifies, based on the request, that thesystem process is associated with enterprise information; and computerreadable program code that grants, to a software platform, restrictedaccess to the enterprise data using a hypervisor.

A further aspect of the invention provides a method comprisingreceiving, from a peripheral device, a request to execute a systemprocess; identifying, based on the request, that the system process isattempting to access non-enterprise information; identifying, based onthe request, that the system process is attempting to access enterpriseinformation; and restricting the system process to one of: thenon-enterprise information and the enterprise information using at leastone of: firmware and hardware.

For a better understanding of exemplary embodiments of the invention,together with other and further features and advantages thereof,reference is made to the following description, taken in conjunctionwith the accompanying drawings, and the scope of the claimed embodimentsof the invention will be pointed out in the appended claims.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates an example method of protecting enterprise data ateach system layer.

FIG. 2 illustrates a computer system.

DETAILED DESCRIPTION

It will be readily understood that the components of the embodiments ofthe invention, as generally described and illustrated in the figuresherein, may be arranged and designed in a wide variety of differentconfigurations in addition to the described exemplary embodiments. Thus,the following more detailed description of the embodiments of theinvention, as represented in the figures, is not intended to limit thescope of the embodiments of the invention, as claimed, but is merelyrepresentative of exemplary embodiments of the invention.

Reference throughout this specification to “one embodiment” or “anembodiment” (or the like) means that a particular feature, structure, orcharacteristic described in connection with the embodiment is includedin at least one embodiment of the invention. Thus, appearances of thephrases “in one embodiment” or “in an embodiment” or the like in variousplaces throughout this specification are not necessarily all referringto the same embodiment.

Furthermore, the described features, structures, or characteristics maybe combined in any suitable manner in at least one embodiment. In thefollowing description, numerous specific details are provided to give athorough understanding of embodiments of the invention. One skilled inthe relevant art may well recognize, however, that embodiments of theinvention can be practiced without at least one of the specific detailsthereof, or can be practiced with other methods, components, materials,et cetera. In other instances, well-known structures, materials, oroperations are not shown or described in detail to avoid obscuringaspects of the invention.

The illustrated embodiments of the invention will be best understood byreference to the figures. The following description is intended only byway of example and simply illustrates certain selected exemplaryembodiments of the invention as claimed herein. It should be noted thatthe flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, apparatuses, methods and computer program products accordingto various embodiments of the invention. In this regard, each block inthe flowchart or block diagrams may represent a module, segment, orportion of code, which comprises at least one executable instruction forimplementing the specified logical function(s).

It should also be noted that, in some alternative implementations, thefunctions noted in the block may occur out of the order noted in thefigures. For example, two blocks shown in succession may, in fact, beexecuted substantially concurrently, or the blocks may sometimes beexecuted in the reverse order, depending upon the functionalityinvolved. It will also be noted that each block of the block diagramsand/or flowchart illustration, and combinations of blocks in the blockdiagrams and/or flowchart illustration, can be implemented by specialpurpose hardware-based systems that perform the specified functions oracts, or combinations of special purpose hardware and computerinstructions.

Specific reference will be made here below to FIG. 1. It should beappreciated that the processes, arrangements and products broadlyillustrated therein can be carried out on, or in accordance with,essentially any suitable computer system or set of computer systems,which may, by way of an illustrative and non-restrictive example,include a system or server such as that indicated at 12′ in FIG. 2. Inaccordance with an example embodiment, most if not all of the processsteps, components and outputs discussed with respect to FIG. 1 can beperformed or utilized by way of a processing unit or units and systemmemory such as those indicated, respectively, at 16′ and 28′ in FIG. 2,whether on a server computer, a client computer, a node computer in adistributed network, or any combination thereof.

As discussed herein, vulnerability of a user device can lead tovulnerability of enterprise data. This is because vulnerable sharedsoftware stacks generally processes enterprise and non-enterprise dataconcurrently. Thus, vulnerabilities are present in every layer of thestack. Because most operating system (OS) kernels are monolithic (i.e.entire executable runs inside a single address space). Malicious datacan craft attack to exfiltrate enterprise data as well as non-enterprisedata.

Enterprises are increasingly embracing the Bring Your Own Device (BYOD)paradigm, where employees can use their personal devices, especiallymobile devices, for official work. However, this scenario can create avulnerable software stack on a mobile device that concurrently processesboth enterprise and non-enterprise data. Because vulnerabilities couldbe present in every layer of the software stack (including applicationsprovided by the enterprise), a remote adversary could craft maliciousnon-enterprise data flows to compromise one or more software layers, andthereby steal enterprise data.

Attacks may compromise multiple layers simultaneously, thus the problembecomes how to craft an approach that guarantees confidentiality ofenterprise data when no layer of the stack can be trusted, because theydo not operate in isolation. As stated, most OS kernels operate inside asingle address space, thus, device hardware functions according to astated functional specification.

Because the mobile user (e.g., employee) is trusted not to exfiltrate acompany's enterprise data, most security protocols and protections arecircumvented because insider attacks are not typically addressable.Therefore, when a remote attacker can exploit vulnerabilities in theVirtual Machine Manager (VMM), OS kernel, and applications typicalsecurity measures are ineffective. Malicious or compromised code maycollude arbitrarily. Thus, an attacker may be able access enterprisedata via explicit reads to locations containing data.

An attacker may not need to infer data values as a function of a sharedexecution state (e.g., no implicit channels may be required). Moreover,an attacker may not use side or covert channels to infer data. In oneembodiment, an application may execute with OS or VMM privilege. In afurther embodiment, the OS kernel could execute with VMM privilege.Thus, arbitrary privilege escalation attacks are made possible. Becausethe application layer can collude with the OS kernel and the VMM toexfiltrate data, no specific layer can be trusted during a potentialattack.

Because each layer of software execution may be compromised, anembodiment may only rely on hardware and firmware to ensure security.Thus, an embodiment may provide a holistic approach that protects theconfidentiality of any enterprise data across all layers of the softwareor stack. This allows an embodiment to ensure security even when the OSkernel and applications are malicious and can collude without requiringany hardware modifications.

Thus, an embodiment provides a technical improvement to mobile devicesby ensuring that enterprise data cannot be stolen, even if theenterprise data is mixed with non-enterprise data, whose handling isunmodified for privacy reasons. In one embodiment, a combination ofmemory permissions is used to modify the parameters of any and allsystem calls (e.g., the approximately four hundred systems calls of atypical Linux Kernel), and control of data exchanged at thesoftware-peripheral interface. In a further embodiment, data can befreely shared between user processes and processes dealing withenterprise data, without requiring modifications to applications,middleware, and even the semantics of systems calls. In one embodiment,the processing of system calls is left entirely to the kernel and thekernel is permitted to directly manage peripheral devices.

A memory element (ME) as referred to herein, is anarchitecturally-visible device in a computing system that stores bitstrings. Additionally, the term ME refers to an actual hardware device,and not to a logical representation such as virtual memory. Generally, aset of ME(s) may be divided into three disjoint sets: (1) the set of allcentral processing units (CPU) registers (C), the set of all RAMlocations (M), and the set of all peripheral device registers (P).Additionally, the above sets are disjoint in a physical sense i.e., theME(s) that are part of each uniquely identifiable hardware device in acomputing system will fall into one of the three sets.

Logically, an embodiment may use ME(s) in one set as though they belongto another set. For example, an embodiment may use of disk blocks asswap space to extend Random Access Memory (RAM) locations, and the useof RAM locations as graphics memory. The enterprise data set is the setof all ME(s) that hold enterprise data. The non-enterprise data set isthe set of all ME that do not hold enterprise data. It should also beunderstood, that the term code stack or stack as used herein is inreference to the set of all software (other than firmware) that executeson the CPU of an electronic device. Generally, a code stack consists ofthe OS kernel, middleware (containing among other things standardlibraries, language runtimes, and daemons), and applications.

Generally, the CPU of the mobile device has three modes of execution:(1) an unprivileged user mode, (2) a privileged kernel or supervisormode, and (3) a privileged hypervisor mode. In this architecture systemthe hypervisor mode is more privileged than the supervisor mode.Because, as discussed herein, an embodiment may operate in hypervisorymode, it is not required that a code stack execute in kernel mode anduser mode. In fact as a consequence of an embodiment operating inhypervisory mode, all execution of the code stack could occur in kernelmode, user mode, or in some combination of both, whichever the attackerdeems most advantageous.

In addition to applications installed directly on a mobile device, anembodiment must be able to manage peripheral level attacks. In oneembodiment, the contents of a peripheral device ME(s) is transferredinto CPU registers or RAM locations before being used as arguments ofCPU instructions. Due to the nature of peripheral devices, an embodimentmay also classify peripherals into either (1) conduit peripherals or (2)processing peripherals. Conduit peripherals do not perform anycomputation on the data input to them either from within or outside thecomputing system. Generally, they only copy or move data; examplesinclude disk, network, and peripheral bus controllers. Processingperipherals perform computation on the data input to them; examplesinclude video and audio hardware. It should be understood by thoseskilled in the art that a processing peripheral must also be conduitperipheral but the converse is not true.

In one embodiment, all computation on enterprise information takes placewithin middleware and/or applications. In an additional embodiment, theOS kernel may perform computations (e.g., encryption of data) forperformance and security reasons. In a further embodiment, applicationsand middleware need only read and write to ME(s) in the set M and theset C during for correct execution. Thus, all access to ME(s) in the setP happen via the OS kernel through the system call mechanism.

The CPU an embodiment may have hardware support for virtualizationincluding memory virtualization (e.g., Intel VT-x technology withextended page tables (EPT) and ARM virtualization extensions with Stage2 page tables). INTEL is a registered trademark of Intel Corporation inthe United States of America and other countries. ARM is registeredtrademark of ARM LLC in the United States of America and othercountries. In a further embodiment, the virtualization extensions can beimplemented as a separate privilege level or as a separate CPU mode.

One embodiment, may have an input output memory management unit (IOMMU)that can translate addresses issued by peripheral devices for directmemory access (DMA) reading and writing, that can prevent DMA reads orwrites or both from peripheral devices to RAM pages. Additionally, in anembodiment, the system physical address map, which states where in thephysical address space the CPU, RAM, ROMs, peripheral device registers,etc. are mapped, may be fixed during platform design and/or specified bya device manufacturer in the platform manual.

Additionally, in an embodiment, the inputs to one or more peripheraldevices that is required to be transferred to software for executing onthe CPU may come from one of four sources: (1) persistent storagelocations (e.g., hard disk drive or flash memory sectors), (2)environmental inputs (e.g., image data from cameras, audio data frommicrophones, movement data from accelerometers and other sensors), (3)user input (e.g., keyboard input, touchscreen input, mouse input,trackpad input, etc.), and (4) other computer systems (e.g., via thenetwork interfaces).

In a further embodiment, the outputs handed to peripheral devices fromsoftware executing on the CPU can go to one or more of the followingsinks: (1) persistent storage locations (e.g., hard disk drives, flashmemory sectors, etc.), (2) display, and (3) other computer systems(e.g., via the network interfaces). In order to transfer data betweenthe software executing on the CPU and the peripheral devices, anembodiment may use one of: (1) DMA reads or writes from RAM locations,and/or (2) reads or writes of peripheral device registers by softwareresulting in data being transferred between CPU registers or RAMlocations, and peripheral device registers.

In one embodiment, peripheral device registers are accessed via thememory-mapped input output (MMIO) mechanism only, and not via port-basedinput output. Additionally, an embodiment may be extended to take careof port-based input output. In another embodiment, data may only betransferred between peripheral devices using the CPU as an intermediary(e.g., there is no facility for peer-to-peer data transfer betweenperipheral devices).

Moreover, in an embodiment, peripheral devices may not copy all or partof data written to them from CPU/RAM registers or received by them fromexternal sources or control registers. Asserting a reset on a peripheraldevice may, in an embodiment, reset all its architecturally-visibleregisters to their reset values, as defined by the device manufacturer.

Based on the factors and characteristics discussed herein, an embodimentwill attempt to keep implementation as small as possible to aid formalverification and reduce attack surface. This may done to in an effort toensure a hardware change is required or that modifications toapplications and middleware may be required. An embodiment may also keepsecurity mechanisms transparent to the user to eliminate cognitive loadand prevent user errors.

Thus, if a component of the code stack has read access to ME(s) in theenterprise data set in unencrypted (e.g., plaintext) form, then itshould not have write access to ME(s) in the non-enterprise data set.Additionally, if a component of the code stack has write access to theME(s) in the non-enterprise data set then it should not have read accessto ME(s) containing plaintext enterprise data.

By way of non-limiting example, an embodiment may exist where it isoperating in a state where either there is no enterprise data on thedevice, or if present, it is only present as encrypted data inpersistent storage locations. Also, data input sources other thanpersistent storage location may be environmental inputs, user inputs,and network inputs, which need not be treated as enterprise datasources. In this state, no action needs to be taken by an embodiment.When in this state, an embodiment must transfer enterprise data into RAMlocations or CPU registers for processing. This happens as a result ofinstructions executed by software running on the CPU.

In a further embodiment, any data obtained as an input from anyperipheral device must be uniquely identifiable as belonging to theenterprise or not. As discussed herein, peripheral devices can beclassified into conduit peripherals and processing peripherals. Based onthis classification, an embodiment may make the following observations:(1) data output to a conduit peripheral by software executing on the CPUcan be encrypted without compromising execution integrity, (2) datainput to a conduit peripheral from outside the physical boundaries ofthe mobile device will be encrypted only if at least one entity in thechain supplying the data encrypts the data, and (3) data input to aprocessing peripheral either from software executing on the CPU or fromoutside the physical boundaries of the mobile device cannot be encryptedwithout compromising execution integrity as processing peripheralscannot compute on encrypted inputs. Based on these observations, anembodiment may set the following requirements for ensuringconfidentiality of enterprise data present in ME(s) of the set P.

Firstly, an embodiment may ensure all enterprise data transferred fromME(s) in the sets C and M to ME(s) of conduit peripherals is encrypted.In addition, an embodiment may ensure that no component of the codestack can read the ME(s) of peripheral devices containing plaintextenterprise data. Assuming the above, in one embodiment, the only CPUmodes available to the code stack are kernel mode and user mode. Thus, afurther embodiment may only permit software executing in the user modeof the CPU to read the ME(s) of the set M containing enterprise data.Another embodiment, may then prevent software executing in the kernelmode of the CPU from reading the ME(s) of the set M containingenterprise data. An embodiment may also prevent software executing inthe user mode of the CPU from reading any ME physically or logicallyassociated with one or more peripheral devices.

Additionally, when a user execution context processing enterprise datatransfers the CPU to kernel mode, an embodiment may save and zero outall CPU registers except those containing system call parameters. Afurther embodiment may modify the system call parameters passed by usermode software executing with enterprise data to the kernel mode. Bydoing this, the embodiment ensures that reads of the system callparameters do not compromise confidentiality of enterprise data whilepreserving the semantics of the system calls. Given that in anon-malicious code stack, applications and middleware execute in theuser mode of the CPU and the OS kernel executes in the kernel mode, theabove embodiments are sufficient to ensure correct execution for anon-malicious stack.

Regarding the management of peripheral devices, an embodiment mayincorporate all device handling, and therefore device drivers and onlyallow the code stack access to devices via hypercalls. However, thisapproach may cause the code size of an embodiment to be overlyburdensome.

Therefore, another embodiment may tag input data (e.g., network data),based on one or more assumptions. Persistent storage tagged at filegranularity and flags in file system metadata may indicate enterprisefiles. Peripherals that provide environmental data input (e.g.,microphone, camera, etc.), and user input (e.g., keyboard, touchscreen,trackpad, etc.) are tagged at device granularity. Thus, at any giventime, all input from these classes of peripherals are treated asenterprise or not.

One embodiment may communicate directly with a special-purposeapplication via a hypercall to enable user tagging. Thus, a user mayselect peripherals to be tagged as enterprise and awaits confirmationfrom an embodiment that tagging is successful before proceeding.Application memory is thus protected and trusted path terminologybetween application and embodiment exists because the embodimentintercepts all user to kernel switches. In a further embodiment, anapplication disk binary image is encrypted, thereby protecting theintegrity before it is executed by the kernel. A kernel can only performdenial of service (DoS) attacks (e.g., by not scheduling the app whenrequested).

Once a user has tagged a peripheral as enterprise, an embodiment mayrequest the kernel to cease all input output to the selected peripheral,reset peripheral, and report the condition by returning. An embodimentmay then un-map all MMIO registers from the kernel space and map it intoaddress space. An embodiment then resets the device and request thekernel to perform a post-reset initialization of the device and return.Thus, any reads and writes performed by kernel to the device MMIOregisters will trap to the embodiment. An embodiment then performs thereads after verifying that the kernel is not attempting to read devicedata registers (because they are assumed to contain enterprise data).Based on the aforementioned steps, an embodiment then has the kernelreturn a message after initializing device to inform user thatperipheral is now tagged as an enterprise peripheral.

An embodiment may also use direct memory access (DMA) for data transfer.Accordingly, an embodiment requests the kernel to cease all input outputto a selected peripheral and report this condition by returning. Similarto above, an embodiment them un-map all MMIO registers from the kernelspace and map it into address space. An embodiment then resets thedevice and request the kernel to perform a post-reset initialization ofall device functions except DMA and return. Thus, any reads and writesperformed by kernel to device MMIO registers will trap to theembodiment. An embodiment then performs the reads after verifying thatthe kernel is not attempting to read device data registers (because theyare assumed to contain enterprise data). Based on the aforementionedsteps, an embodiment then performs DMA initialization of the device bysetting up appropriate control structures in its own memory andprogramming the DMA specific registers of the device and informs theuser that peripheral is now tagged as an enterprise peripheral.

An embodiment may also use encrypted data in combination with DMA. Forsimplicity purpose, details below assume a single page in handled. Itshould be clear to one skilled in the art how to extend the example tomultiple pages. First, a kernel may receive encrypted enterprise datavia DMA from a peripheral with tag indicating enterprise data. Then,based on tag, the kernel may request decryption of the data. Based onthe request, an embodiment then removes R and X permissions for the pagein the virtualization page tables for the page, and prevents DMA readsand writes to the page via the input output memory management unit(IOMMU) page tables. A further embodiment may then flush the memorymanagement unit (MMU) table and the IOMMU table. Once the MMU and IOMMUhave been flushed, an embodiment may add the intermediate physicaladdress (IPA) of the page to the enterprise set, perform the decryptionand return to the kernel.

As part of adding page addresses to the DMA scatter-gather list, akernel may call on an embodiment to request for DMA read permissions toenterprise pages. An embodiment then checks to see if the page is inenterprise set, and if not returns and error. If the page is in theenterprise set, an embodiment may encrypt the page contents and make avirtualization page table entry translating the IPA invalid. Therebyensuring the code stack cannot read or write the contents of the page.An embodiment then grants DMA read permissions in the IOMMU page tableentry translating the IPA, flushes the MMU table and IOMMU table, andreturns.

For non-encrypted data and DMA when an entire peripheral has been taggedenterprise, all DMA happens to and from memory. Once again forsimplicity purposes, the below steps assume a single page of data isbeing transferred via DMA, as extension to multi-page transfers would bestraightforward to one skilled in the art. Firstly, a kernel requests anembodiment to set up DMA transfer of data from the device into RAM. Anembodiment then programs the DMA using a physical page in memory as thetarget. After a period of time, an embodiment may receive an interruptfrom a device indicating completion of the DMA. Thereafter, anembodiment may create a mapping for the page in the virtualization pagetables, and remove R and X permissions for the page. The page may thenbe added to the enterprise data set. An embodiment then flushes the MMUtable and returns the IPA of the page to the kernel.

A kernel may call an embodiment with IPA of a page from which data is tobe sent to the peripheral via DMA. An embodiment then marks thevirtualization page table entry translating the IPA invalid, ensuringthat the code stack cannot read or write the contents of the page.Thereafter, the embodiment flushes the MMU table, programs the DMA usingthe physical address corresponding to the IPA, and returns,

For non-encrypted Data and Memory Mapped Input Output (MMIO), a Kernelcalls on an embodiment requesting to send or receive data from aperipheral passing as parameter an IPA that contains data to be sent orthe receive buffer. An embodiment then checks if the IPA is in theenterprise IPA set, and if not adds the IPA to the enterprise IPA set,adds a translation entry for the IPA in the virtualization page table,removes R and X permissions, and flushes the MMU table. An embodimentmay then write the data to the MMIO send register or read data from theMMIO receive register of the peripheral and returns.

Regarding memory protections, an embodiment utilizes a virtual machinemonitor (VMM) to virtualize physical memory, with the result that thephysical addresses used by a virtual machine (VM) could be differentfrom the physical addresses that are sent on the memory bus. Therefore,the VMM needs to translate a VM's physical addresses (e.g., theintermediate physical addresses (IPA)) to the physical addresses sent onthe memory bus (e.g., the system physical addresses (SPA)). A CPU withvirtualization support may then provide a separate set of page tablesfor this purpose (e.g., the stage 2 page tables). The page tablesmaintained by the kernel in a VM for translating virtual addresses toIPA(s) may be called stage 1 page tables. The stage 2 page tables mapmemory at the granularity of a page and each page has read (R), write(W), and execute (X) permissions. The permissions used by the CPU foraccessing a page are the more restrictive of those in the stage 1 andstage 2 page tables.

With regard to memory protection, an embodiment uses stage 2 page tablesto set memory permissions over intermediate physical addresses pageframes. The stage 2 page tables are then set for a one-to-onetranslation of IPA to SPA (e.g., each IPA has a unique SPA, thus IPAaliasing is not possible).

A further embodiment, as discussed herein, may internally maintain adata structure called the enterprise data set. This set contains all theIPA(s) that contain enterprise data, with a bit indicating if the IPAbelongs to a user process or the kernel. In one embodiment, it is theSPA page frames that hold data. This means that ideally the SPAcontaining enterprise data should tracked. However, tracking IPA(s) maybe insufficient. This is because the one-to-one translation of IPA(s) toSPA in the stage 2 page table ensures that there can be no aliasing ofmultiple IPA(s) to the same SPA.

By way of specific example, permission handling may be described inthree stages: (1) the first time a user process tries to read enterprisedata, (2) when a user process that has already read enterprise data inthe past is re-started as a result of the kernel's return to user mode,and (3) handling of enterprise data when the kernel executes enterprisedata enters RAM via peripherals. An embodiment may mark pages containingenterprise data read-only in stage 2 page tables.

Thus, any attempt to read causes a permission fault. This faultindicates if it occurs in user mode or kernel mode. If the faultoccurred in user mode, then a user process is attempting to read orcompute with enterprise data for the first time. Based on thisdetermination, an embodiment may take the following steps. First, anembodiment may walk the stage 1 page tables of this user process usingthe CPU's page table pointer. Then an embodiment may add to theenterprise data set all the IPA(s) whose user/supervisor bit is set touser in the stage 1 page tables. It may also, record the status of theuser/supervisor bit in the enterprise data set. Then, for each IPA inthe enterprise data set, an embodiment may give R, W, and X permissionsin the stage 2 page tables. An embodiment then marks all of the state 2translation entries of all IPA(s) not given R, W, and X permissions inthe previous step invalid (e.g., both kernel and MMIO IPA(s)). Thetables is then flushed and the embodiment returns.

When a user process that has previously read enterprise data is switchedinto, an embodiment may perform the steps of: walk the stage 1 pagestables of this user process using the CPU's page table pointer; checkwhether each IPA in the page table whose user/supervisor bit is set touser is present in the enterprise data set; and if an IPA is notpresent, add it to the set along with the status of the user/supervisorbit. Thus, for each IPA in the enterprise data set, an embodiment maygive R, W, and X permissions in the stage 2 page tables and mark all thestage 2 translation entries of all IPA(s) not given R, W, and Xpermissions in the previous step invalid. (e.g., both kernel and MMIOIPA(s)). The tables is then flushed and the embodiment returns. When akernel executes a process, an embodiment may mark all IPA(s) in theenterprise data set W in the stage 2 page tables, mark all other IPA(s)R, W, and X and valid, flush the tables, and return

One embodiment does not identify individual user processes. Instead,each process that has previously read an enterprise IPA will receivesimilar permissions. This allows data sharing between enterpriseprocesses. Additionally, the first time a process tries to read anenterprise IPA all the IPA(s) in its stage 1 page table automaticallyget marked as enterprise IPA(s). In a further embodiment, when anyenterprise user process executes, it can read, write, and execute, alluser IPA(s) with enterprise data. However, it cannot access eitherkernel IPA(s) or MMIO IPA(s). Additionally, any IPA that an enterpriseuser process can access will be in included in the enterprise data set.

In another embodiment, when a kernel executes, no IPA containingenterprise data will be readable. Thus, virtual address aliasing (e.g.,multiple virtual addresses mapping to the same IPA) will not have aneffect because an embodiment sets permissions on IPA page frames.Moreover, one-to-one translation of IPA(s) to SPA(s) in the stage 2 pagetables ensures that each SPA is accessed with exactly one set of stage 2permissions.

When handling in-kernel copying of enterprise data, a kernel does notread permissions to enterprise IPA. Instead, an embodiment performs acopy on behalf of kernel. In order to know the source to copy from, anembodiment may rely on two characteristics: destination and size to becopied. For the strcpy( ) family of functions in the kernel, anembodiment may identify a function by faulting the kernel programcounter and reading the parameters off the kernel stack. Otherwise, anembodiment may fall back to disassembling the faulting instruction inorder to learn the source via destination and size of copy.

One embodiment may translate virtual address of destinations to an IPAusing kernel's stage 1 page tables. Then, if the IPA of a destinationaddress is not in the enterprise IPA set, it is added to the enterpriseIPA set and set with a user/supervisor flag of the corresponding entryto supervisor. An embodiment may then perform the copy and returnfunctions, thereby handling system call parameters.

In an embodiment, there may be at least three types of parameters forsystem calls: (1) those generated by a kernel and passed to a user spaceas a return value of a previous system call (e.g., file descriptors,etc.), (2) those generated and passed from a user space to a kernel(e.g., virtual addresses, array counts, etc.), and (3) constants definedin the system call specification (e.g., system call numbers, flags,etc.). Generally, types (1) and (3) are straightforward: for (1) anembodiment may check if a value being passed from user to kernel waspreviously returned to user by kernel, and for (3) an embodiment maycheck if a constant being passed is appropriate for a system call asdefined by the sys call specification. Types (2) however, needs to betransformed in a manner that will not affect the semantics of the systemcall involved as because there is no way to verify its value.

A non-limiting list of semantic system call parameters maybe: indicesinto kernel data structures (e.g., pid, gid, fd, etc.); pointers withvirtual addresses (passed from user to kernel, and from kernel to user);user and group identifications (IDs); time parameters (e.g., timers,sleep, timeouts, etc.); major and minor device numbers; file offsets;array counts; file system pathnames; name strings (e.g., host name,network name, process name, etc.); scheduling priorities (e.g., nicevalues, etc.).

Thus, an embodiment, as discussed herein, broadly provides a method forprotecting enterprise data at each system layer. The method comprisingreceiving, on an electronic device, a request to execute a systemprocess at 101. Once the request is received, an embodiment analyzes itto determine if the system process is attempting to accessnon-enterprise information at 102. If it is determined that the requestis not accessing non-enterprise information, then it can be inferredthat it is only accessing enterprise information and the request may begranted at 104. However, if the system process does require access tonon-enterprise data, an embodiment further checks to determine if thesystem process also needs access to enterprise information at 103. Ifthe determination is made that the system process does not need accessto enterprise information, and thus only needs to access non-enterpriseinformation, the request can be grated at 104. Alternatively, if it isdetermined that the system process requires access to bothnon-enterprise information at 102 and enterprise information at 103, anembodiment may restrict the system process to only one of the requesteddata sets at 105.

As shown in FIG. 2, computer system/server 12′ in computing node 10′ isshown in the form of a general-purpose computing device. The componentsof computer system/server 12′ may include, but are not limited to, atleast one processor or processing unit 16′, a system memory 28′, and abus 18′ that couples various system components including system memory28′ to processor 16′. Bus 18′ represents at least one of any of severaltypes of bus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, and a processor or localbus using any of a variety of bus architectures. By way of example, andnot limitation, such architectures include Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnects (PCI) bus.

Computer system/server 12′ typically includes a variety of computersystem readable media. Such media may be any available media that areaccessible by computer system/server 12′, and include both volatile andnon-volatile media, removable and non-removable media.

System memory 28′ can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 30′ and/or cachememory 32′. Computer system/server 12′ may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 34′ can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 18′ by at least one datamedia interface. As will be further depicted and described below, memory28′ may include at least one program product having a set (e.g., atleast one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 40′, having a set (at least one) of program modules 42′,may be stored in memory 28′ (by way of example, and not limitation), aswell as an operating system, at least one application program, otherprogram modules, and program data. Each of the operating systems, atleast one application program, other program modules, and program dataor some combination thereof, may include an implementation of anetworking environment. Program modules 42′ generally carry out thefunctions and/or methodologies of embodiments of the invention asdescribed herein.

Computer system/server 12′ may also communicate with at least oneexternal device 14′ such as a keyboard, a pointing device, a display24′, etc.; at least one device that enables a user to interact withcomputer system/server 12′; and/or any devices (e.g., network card,modem, etc.) that enable computer system/server 12′ to communicate withat least one other computing device. Such communication can occur viaI/O interfaces 22′. Still yet, computer system/server 12′ cancommunicate with at least one network such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 20′. As depicted, network adapter 20′communicates with the other components of computer system/server 12′ viabus 18′. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 12′. Examples include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

This disclosure has been presented for purposes of illustration anddescription but is not intended to be exhaustive or limiting. Manymodifications and variations will be apparent to those of ordinary skillin the art. The embodiments were chosen and described in order toexplain principles and practical application, and to enable others ofordinary skill in the art to understand the disclosure.

Although illustrative embodiments of the invention have been describedherein with reference to the accompanying drawings, it is to beunderstood that the embodiments of the invention are not limited tothose precise embodiments, and that various other changes andmodifications may be affected therein by one skilled in the art withoutdeparting from the scope or spirit of the disclosure.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Smalltalk, C++ or the like, andconventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions. These computer readable programinstructions may be provided to a processor of a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructions,which execute via the processor of the computer or other programmabledata processing apparatus, create means for implementing thefunctions/acts specified in the flowchart and/or block diagram block orblocks. These computer readable program instructions may also be storedin a computer readable storage medium that can direct a computer, aprogrammable data processing apparatus, and/or other devices to functionin a particular manner, such that the computer readable storage mediumhaving instructions stored therein comprises an article of manufactureincluding instructions which implement aspects of the function/actspecified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

What is claimed is:
 1. A method comprising: utilizing at least oneprocessor to execute computer code that performs the steps of:receiving, on an electronic device, a request to execute a systemprocess; determining, using a processor, if the electronic devicecontains enterprise information; thereafter, identifying, based on therequest, that the system process is associated with enterpriseinformation; and granting, to a software platform, restricted access tothe enterprise data using a hypervisor.
 2. The method of claim 1,wherein the software platform comprises at least one of: an operatingsystem kernel and a system application.
 3. The method of claim 1,wherein system process comprises at least one of: reading informationfrom memory, writing information to memory, reading information fromdisk space, writing information to disk space, executing an action oninformation in memory, and executing an action on information in diskspace.
 4. The method of claim 3, wherein the request is encoded by thehypervisor; and wherein the encoded system process is carried out by anoperating system kernel
 5. The method of claim 1, wherein the requestoriginates at a peripheral device.
 6. The method of claim 5, furthercomprising: determining that the peripheral device is associated withthe enterprise data.
 7. The method of claim 5, wherein the peripheraldevice comprises a conduit peripheral device.
 8. The method of claim 5,wherein the peripheral device comprises a processing peripheral device.9. The method of claim 1, wherein the hypervisor operates on at leastone of a hardware level and a firmware level.
 10. An apparatuscomprising: at least one processor; and a computer readable storagemedium having computer readable program code embodied therewith andexecutable by the at least one processor, the computer readable programcode comprising: computer readable program code that receives, on theapparatus, a request to execute a system process; computer readableprogram code that determines, using a processor, if the apparatuscontains enterprise information; computer readable program code thatthereafter, identifies, based on the request, that the system process isassociated with enterprise information; and computer readable programcode that grants, to a software platform, restricted access to theenterprise data using a hypervisor.
 11. A computer program productcomprising: a computer readable storage medium having computer readableprogram code embodied therewith, the computer readable program codecomprising: computer readable program code that receives, on anelectronic device, a request to execute a system process; computerreadable program code that determines, using a processor, if theelectronic device contains enterprise information; computer readableprogram code that thereafter, identifies, based on the request, that thesystem process is associated with enterprise information; and computerreadable program code that grants, to a software platform, restrictedaccess to the enterprise data using a hypervisor.
 12. The computerprogram product of claim 11, wherein the software platform comprises atleast one of: an operating system kernel and a system application. 13.The computer program product of claim 11, wherein system processcomprises at least one of: reading information from memory, writinginformation to memory, reading information from disk space, writinginformation to disk space, executing an action on information in memory,and executing an action on information in disk space.
 14. The computerprogram product of claim 13, wherein the request is encoded by thehypervisor; and wherein the encoded system process is carried out by anoperating system kernel
 15. The computer program product of claim 11,wherein the request originates at a peripheral device.
 16. The computerprogram product of claim 15, further comprising: computer readableprogram code that determines that the peripheral device is associatedwith the enterprise data.
 17. The computer program product of claim 15,wherein the peripheral device comprises a conduit peripheral device. 18.The computer program product of claim 15, wherein the peripheral devicecomprises a processing peripheral device.
 19. The computer programproduct of claim 11, wherein the hypervisor operates on at least one ofa hardware level and a firmware level.
 20. A method comprising:receiving, from a peripheral device, a request to execute a systemprocess; identifying, based on the request, that the system process isattempting to access non-enterprise information; identifying, based onthe request, that the system process is attempting to access enterpriseinformation; and restricting the system process to one of: thenon-enterprise information and the enterprise information using at leastone of: firmware and hardware.